Return submission index to track down completion of async callbacks #6360
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
wgpu-native is upgrading to latest versions of
webgpu-headers
(see gfx-rs/wgpu-native#427), and a notable change since the last sync is the introduction ofWGPUFuture
. Such structure holds au64
, from which we must be able to tell whether the async operation has completed.A good candidate for the payload of
WGPUFuture
is the submission index already used in some places (andu64::MAX
to mean "a future that is already resolved, probably because submission failed"). The only issue is that submit operations do not necessarily return a submission index.Description
This PR makes functions
buffer_map_async
,add_work_done_closure
,map_async
,queue_on_submitted_work_done
return the submission index that can later be used to check that the operation completed.Testing
This is a WIP, I need feedback on the use of
last_successful_submission_index
inqueue_on_submitted_work_done
(is this the right fallback?), feedback about how to check that an operation completed from its submission index, and there is something to discuss aboutmap_async
:active_submission_index
to make sure the operation is not considered complete too early, but maybe this can have the callback be invoked with some delay if the buffer mapping operation was not the last in queue?map_async
returns, we do not know yet the true submission index of the map operation (it may be lower than theactive_submission_index
, right? If not then the proposed solution is ok, otherwise should we trigger triage right away? I guess there is a good reason why it is done separately though.